Rewrites error messages across packages/cli/src/commands/ to follow
the What / Where / Saw vs. wanted / Fix strategy from CLAUDE.md's
new Error Messages section.

Sources:
- scan/cmd-scan-create.mts: 5 throws (ecosystems + 4 numeric flags)
- scan/cmd-scan-reach.mts: 4 throws (ecosystems + 3 numeric flags)
- scan/cmd-scan-list.mts: 2 throws (--page, --per-page)
- organization/cmd-organization-dependencies.mts: 2 throws (--limit, --offset)
- audit-log/cmd-audit-log.mts: 2 throws (--page, --per-page)
- threat-feed/cmd-threat-feed.mts: 1 throw (--per-page)
- fix/cmd-fix.mts: 1 logger.fail (--ecosystems)
- ask/cmd-ask.mts: 1 InputError (missing QUERY)
- login/cmd-login.mts: 1 InputError (non-interactive TTY)
- wrapper/add-socket-wrapper.mts: 1 throw (fs.appendFile failure)
- wrapper/postinstall-wrapper.mts: 1 throw (nested wrapper setup)
- manifest/convert-gradle-to-maven.mts: 1 throw (spawn returned no output)
- fix/coana-fix.mts: 1 throw (coana returned non-array JSON)
- config/handle-config-set.mts: 1 throw (missing VALUE)

Tests updated to match new substrings (regex patterns for easier
future evolution).

All throws previously typed as plain Error that represent user input
validation have been converted to InputError, following the codebase
convention.

Follows strategy landed in #1254.

Switch `(e as Error).message` to `e instanceof Error ? e.message : String(e)` so that when a non-Error value is thrown (strings, objects, null) the error message stays informative instead of becoming 'undefined'.

Same fix as applied to #1260 (iocraft.mts) after Cursor bugbot flagged the pattern on that PR.

Cursor bugbot flagged both add-socket-wrapper.mts and
postinstall-wrapper.mts for rendering I/O errors with the "Invalid
input" title and "Check command syntax with --help" recovery hint
(InputError's display mapping). fs.appendFile failures are permission /
disk / path problems — FileSystemError renders them as "File system
error" with contextual recovery (check file permissions, disk space,
etc.).

Pass the file path (where available) and the ErrnoException code
through so FileSystemError can surface EACCES/ENOSPC/ENOENT-specific
recovery text.

Reported on PR #1255.

Two issues flagged on the fresh review of HEAD:

- FileSystemError duplicates the filepath: the message embeds ${file}
  AND the constructor receives `file` as the path argument. Since
  display.formatErrorForDisplay appends \`(\${error.path})\` automatically,
  this surfaced the path twice. Drop the \${file} interpolation from
  the message — the path arg alone is enough.

- Scan command numeric flag errors overstated validation: \`--pull-request\`
  claimed "non-negative integer" and \`--reach-concurrency\` claimed
  "positive integer," but the checks only rejected NaN. Negatives and
  floats passed through silently. Tighten the validation to match what
  the error messages promise — Number.isInteger + range check at every
  call site (cmd-scan-create.mts for both flags, cmd-scan-reach.mts for
  reach-concurrency).

The third flagged item (FileSystemError vs InputError in the wrapper
commands) was cursor re-flagging a finding already addressed in commit
769170f — the current code already uses FileSystemError. No action.

Previous commit (2269113) dropped the \${file} interpolation from
FileSystemError's message to avoid display.formatErrorForDisplay
double-printing the path (which it appends from error.path). The test
regex still matched the pre-change format — /failed to append socket
aliases to \/etc\/protected-file/ — and wouldn't have matched the new
message.

Assert on the new shape instead:
  - regex matches `failed to append socket aliases (Permission denied)`
  - toMatchObject pins name='FileSystemError' and path='/etc/protected-file'

Drive-by: the existing regex had \./etc\/protected-file/ but the
message never contained that substring after the FileSystemError swap
— so the assertion was silently wrong. Flagged by cursor on #1255.